I've tried to clarify scope here a little better, and fill out some of the additional missing sections.

This project is doing a lot of mapping-of-the-unknown, but it does need to be kept to the minimum required. We currently think we have a decent picture of the landscape so the scope is defined accordingly--although we need to be prepared to discover entirely new universes (I stumbled on the glifio JS stack by accident just prior to writing this proposal!). Where I'm keeping this tight is in the maturity of the output. We're not producing polished docs, we're not even producing docs except where modifications might be trivial activities. We're producing checklists, and have already started that process. We'll scope further work later but we just need to collect this information by exploring and very basic experimenting.

I've sized it at a Small, but that's for 3-5 FTEs, which is much more than we're working with on Sudo at the moment so I want to set that expectation up front.

@anorth @jacobheun I would appreciate some EM eyes to critique my attempts to define a sense of scope.

except where modifications might be trivial activities

I would avoid this regardless of triviality to prevent frequent yet subtle derailments. Reading through this the output seems to best fit a report on the current state of JS clients, and recommendations (stack ranked) for improvements.

Based on the information here it seems that stakeholder interviews should be the first to happen, which would then inform the existing api/client evaluation: Based on what we learned from the stakeholders, what are the libraries we should be focusing our analysis on?

It seems like this is the general path being proposed here, I just want to verify we're not proposing these may be done in parallel. The advantage of doing these in sequence is that we can reduce the footprint of the api we're evaluating and then focus investigation on verifying the observations from the interviews. During validation we may find additional issues that weren't previously raised, but those can be added to the findings of the final report. Overall the scope looks good, but we should ensure to phase it, to avoid splitting focus over too many things.

Scope for this project seems appropriately limited. I wouldn't want that to also limit the scope of recommendations that come out of this, though. E.g. maybe the Lotus RPC API that serves node operators and miners isn't the right abstraction, or transport, or contract-to-impose-on-Lotus for client APIs, and work on the libraries that try to solve that impedance mismatch entrenching a long-term problem?

Updated the "done" to say that the goal is to produce a "brief report" covering the state of the world for these libraries and the Lotus RPC API from the library perspective. It should be quite terse and short and aim for maximal information in minimal words and be useful for scoping and prioritising future work and may feed into documentation efforts.